Automatic anti-spoof for multicast routing

ABSTRACT

A method, system and computer-usable medium are disclosed for performing an automated anti-spoofing configuration operation, comprising: determining whether a source address of an internet protocol (IP) packet is allowed by a receiving interface of a firewall; determining whether the IP packet comprises a multicast packet when the IP packet is allowed by the receiving interface of the firewall; replacing the source address with a rendezvous point address; using the rendezvous point address to determine whether routing path information associated with the multicast packet matches information stored within a multicast routing information base for the receiving interface of the firewall; and, identifying the multicast packet as spoofed when the routing path information associated with multicast packet does not have corresponding information stored within the multicast routing information base.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention relates in general to the field of computers andsimilar technologies, and in particular to software utilized in thisfield. Still more particularly, it relates to a method, system andcomputer-usable medium for automating changes to a firewall's multicastanti-spoofing configuration to improve network security.

Description of the Related Art

Multicasting is a commonly used networking approach for simultaneouslyproviding information, such as streaming media, to a target group ofinformation handling systems. While multicasting is an effective way todeliver large volumes of information to many recipients, it posescertain security risks. In particular, the source(s) of a data streamused in a distributed denial of service (DDoS) attack may be falsified,or spoofed, to hide the identity of a malicious sender or to make itappear it is originating from a trusted source.

In such attacks, a large number of spoofed network addresses are used tohide the actual source, or identity, of the sender. One knownanti-spoofing approach to overcoming such security threats is ingressfiltering, which includes blocking of incoming packets that originatefrom outside the network, but use a source address inside the network.Another approach is egress filtering, which includes blocking ofoutgoing packets that originate from inside the network, but use asource address that is outside the network. One known advantage of suchapproaches is reducing cybersecurity vulnerability by blocking packetsillicitly implemented with spoofed addresses.

SUMMARY OF THE INVENTION

A method, system and computer-usable medium for performing an automatedanti-spoofing configuration operation, comprising: determining whether asource address of an internet protocol (IP) packet is allowed by areceiving interface of a firewall; determining whether the IP packetcomprises a multicast packet when the IP packet is allowed by thereceiving interface of the firewall; replacing the source address with arendezvous point address; using the rendezvous point address todetermine whether routing path information associated with the multicastpacket matches information stored within a multicast routing informationbase for the receiving interface of the firewall; and, identifying themulticast packet as spoofed when the routing path information associatedwith multicast packet does not have corresponding information storedwithin the multicast routing information base.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings. The use of the samereference number throughout the several figures designates a like orsimilar element.

FIG. 1 depicts an exemplary client computer in which the presentinvention may be implemented;

FIG. 2 is a simplified block diagram of an automated multicastanti-spoofing configuration system; and

FIGS. 3a through 3c are a generalized flowchart of the performance ofautomated multicast anti-spoofing configuration system operations.

DETAILED DESCRIPTION

Certain aspects of the present disclosure include an appreciation thatautomated multicast anti-spoof solutions are not currently known.Instead, known multicast anti-spoofing solutions require some degree ofmanual configuration. Certain aspects of the present disclosure includean appreciation that such multicast anti-spoofing are configurations arenot typically enabled by default.

A method, system and computer-usable medium are disclosed for automatingchanges to a firewall's multicast anti-spoofing configuration to improvenetwork security. For purposes of this disclosure, an informationhandling system may include any instrumentality or aggregate ofinstrumentalities operable to compute, classify, process, transmit,receive, retrieve, originate, switch, store, display, manifest, detect,record, reproduce, handle, or utilize any form of information,intelligence, or data for business, scientific, control, or otherpurposes. For example, an information handling system may be a personalcomputer, a mobile device such as a tablet or smartphone, a connected“smart device,” a network appliance, a network storage device, or anyother suitable device and may vary in size, shape, performance,functionality, and price. The information handling system may includerandom access memory (RAM), one or more processing resources such as acentral processing unit (CPU) or hardware or software control logic,ROM, and/or other types of nonvolatile memory. Additional components ofthe information handling system may include one or more storage systems,one or more network ports for communicating externally, as well asvarious input and output (I/O) devices, such as a keyboard, a mouse, anda graphics display.

FIG. 1 is a generalized illustration of an information handling system100 that can be used to implement the system and method of the presentinvention. The information handling system 100 includes a processor(e.g., central processor unit or “CPU”) 102, input/output (I/O) devices104, such as a display, a keyboard, a mouse, and associated controllers,a storage system 106, and various other subsystems 108. In variousembodiments, the information handling system 100 also includes networkport 110 operable to connect to a network 140, which is likewiseaccessible by a service provider server 142. The information handlingsystem 100 likewise includes system memory 112, which is interconnectedto the foregoing via one or more buses 114. System memory 112 furtherincludes operating system (OS) 116 and in various embodiments may alsoinclude an automated multicast anti-spoofing configuration system 118.In one embodiment, the information handling system 100 is able todownload the automated multicast anti-spoofing configuration system 118from the service provider server 142. In another embodiment, theautomated multicast anti-spoofing configuration system 118 is providedas a service from the service provider server 142.

In various embodiments, the automated anti-spoofing configuration system118 performs an automated multicast anti-spoofing configurationoperation. In certain embodiments, the automated anti-spoofingconfiguration operation improves processor efficiency, and thus theefficiency of the information handling system 100, by automatingmulticast anti-spoofing configuration operations. As will beappreciated, once the information handling system 100 is configured toperform the automated multicast anti-spoofing configuration operation,the information handling system 100 becomes a specialized computingdevice specifically configured to perform the automated multicastanti-spoofing configuration operation and is not a general purposecomputing device. Moreover, the implementation of the automatedmulticast anti-spoofing configuration system 118 on the informationhandling system 100 improves the functionality of the informationhandling system 100 and provides a useful and concrete result ofautomating the multicast anti-spoofing configuration of a firewall.

FIG. 2 is a simplified block diagram of an automated multicastanti-spoofing configuration system implemented in accordance with anembodiment of the invention to automate changes to a firewall'smulticast anti-spoofing configuration. In certain embodiments, afirewall 220 may include multi-access network interfaces ‘1’ 222.through ‘n’ 224, a firewall configuration management interface 226, andan automated anti-spoofing configuration system 118. In certainembodiments, one or more of the network interfaces may be an internalnetwork interface or an external network interface. In certainembodiments, the firewall 220 may likewise include a multicast routinginformation base (MRIB), a unicast routing information base (RIB) 230,and an internal network interface 232.

The firewall 220 may likewise include in certain embodiments arepository of multicast anti-spoofing configuration settings 234 and arepository of multicast log entry information 236. In certainembodiments, the firewall configuration management interface 226 isimplemented to receive automated multicast anti-spoofing configurationinstructions from the automated anti-spoofing configuration system 118.In certain embodiments, the firewall 220 may be implemented as anindividual firewall 220, a virtual context firewall 220, or a firewall220 cluster.

Skilled practitioners of the art will be familiar with multicast, whichis commonly used in a network environment for simultaneously providingInternet Protocol (IP) datagrams, or packets, to a target group ofrecipient network addresses in real-time or near real-time. In certainembodiments, the target group recipient network addresses may berespectively associated with a corresponding endpoint device ‘1’ 244through ‘n’ 246. As used herein, an endpoint device refers to aninformation processing system such as a personal computer, a laptopcomputer, a tablet computer, a personal digital assistant (PDA), a smartphone, a mobile telephone, a digital camera, a video camera, or otherdevice capable of storing, processing and communicating data via anetwork, such as an internal network 240. In various embodiments, thecommunication of the data may take place in real-time or near-real-time.

Certain embodiments of the invention may reflect an appreciation thatmultiple source (SRC) network addresses may be used to improve thedelivery speed of an associated multicast data stream to a group ofrecipient network addresses. However, those of skill in the art willlikewise appreciate that multicast is often used in an attempt tocompromise the security of a network. In particular, the SRC address(es)of IP packets in a multicast data stream used in a distributed denial ofservice (DDoS) attack may be falsified, or spoofed, to hide the identityof a malicious sender. More particularly, such falsification or spoofingmay be used to make it appear the multicast data stream is originatingfrom one or more trusted sources. It will likewise be appreciated thatusing multiple spoofed source addresses makes it more difficult todetermine which multicast IP packets actually originate from trustedsources and which do not.

Known anti-spoofing approaches include ingress filtering, which is oftenused as a countermeasure against various spoofing attacks by attemptingto ensure that incoming packets actually originate from the SRC addressthey claim. Certain embodiments of the invention may reflect anappreciation that various approaches for ingress filtering of unicast IPpackets on a router are known. However, such ingress filtering istypically not enabled by default on a router. Likewise, certainembodiments reflect an appreciation that such ingress filtering on arouter may be implemented by manually configuring access lists,automatically comparing a packet's SRC address to its reverse path in aunicast routing table, or a combination thereof. In these embodiments,the packet may be spoofed if the SRC address of the packet does notmatch its reverse path. However, skilled practitioners of the art willlikewise be aware that such spoofing is sometimes used for legitimatepurposes (e.g., network testing), which may reduce the effectiveness ofingress filtering for identifying maliciously spoofed IP packets.

Certain embodiments of the invention may further reflect an appreciationthat such approaches may include automating adjustments to ingresspacket filtering processes according to dynamic routing information,even when network traffic asymmetrical. Likewise, certain aspects of theinvention may reflect an appreciation that such approaches are oftenlimited to router interfaces receiving unicast IP packets from edgenetworks. Certain embodiments of the invention may likewise reflect anappreciation that when ingress packet filtering is used by a router, itis typically implemented as a silent drop, where dropped packets are notlogged.

Certain embodiments of the invention may reflect an appreciation thatingress packet filtering implemented on a firewall 220 is commonlyreferred to as anti-spoofing. More particularly, certain embodiments ofthe invention may reflect an appreciation that such anti-spoofing istypically implemented on a firewall 220 to block incoming packets thatoriginate from outside the internal network 240, but use a SRC addressfrom inside the internal network 240. Likewise, certain embodiments ofthe invention may reflect an appreciation that such anti-spoofing isfrequently implemented on a firewall 220 by default. Furthermore,certain embodiments of the invention may likewise reflect anappreciation that implementing such anti-spoofing on all interfaces of afirewall 220, such as multi-access external network interfaces ‘1’ 222through ‘n’ 224, is often recommended. Likewise, certain embodiments ofthe invention may further reflect an appreciation that packets droppedby such anti-spoofing on a firewall 220 are typically logged and stored.In certain embodiments, information related to the spoofed packets isstored in a repository of IP packet log entry information 236.

Certain embodiments of the invention may reflect an appreciation thatmulticast routing, and especially the use of Protocol IndependentMulticast (PIM) for multicast routing, may result in legitimate packetsfrom certain trusted source IP addresses being received from a differentdirection than unicast IP packets from the same source IP address. Thoseof skill in the art will be familiar with PIM, which broadly refers to afamily of multicast routing protocols used in IP-based networks toprovide one-to-many and many-to-many distribution of data to a targetgroup of recipient network addresses. In particular, PIM ischaracterized as “protocol-independent” as the family of PIM protocolsdoes not include the ability to discover the topology of a network.Instead, it relies upon routing information used by other routingprotocols, such as those used for routing unicast packets.

Certain embodiments of the invention may reflect an appreciation thatPIM is not dependent upon a particular unicast routing protocol. Insteadit is capable of using any currently known unicast routing protocolimplemented within an IP-based network environment, such as the internalnetwork 240 shown in FIG. 2. Certain embodiments of the invention maylikewise reflect an appreciation that PIM does not build its own routingtables. Instead, it is able to use existing unicast routing tables foran IP packet's reverse path forwarding information. Likewise, certainembodiments of the invention may reflect an appreciation that suchreverse path forwarding information can be used advantageously by afirewall 220 in the performance of multicast anti-spoofing operations.

Likewise, certain embodiments of the invention may reflect anappreciation that even in simple network topologies, and even when arendezvous point (RP) is placed close to the sender, a typical firewall220 placement may still only receive multicast IP packets throughinterfaces that also receive unicast IP packets from the same SRCaddress. Certain embodiments of the invention may likewise reflect anappreciation that a network, such as an internal network 240, may needto be highly available. Accordingly, alternative paths, and associatedanti-spoofing, may be incorrectly defined if unicast routing is notworking correctly. Certain embodiments of the invention may furtherreflect an appreciation that manual tuning of anti-spoofing, ordisabling of anti-spoofing, may be required in such cases.

Certain embodiments of the invention may reflect an appreciation thatmulticast dynamic routing uses the PIM protocol to create a multicastrouting topology, which typically results in a need to reconfigureexisting anti-spoof rules. Accordingly, certain embodiments of theinvention may reflect a further appreciation that such reconfigurationcan be error-prone, which in turn may result in causing security issues.Likewise, certain embodiments of the invention may reflect anappreciation that when using access lists or ingress packet filtering asan anti-spoofing approach, it is possible to use a different filter formulticast traffic. Furthermore, certain embodiments of the invention mayreflect an appreciation that PIM multicast routing and other knownanti-spoofing approaches have been used together for some time. However,an automated anti-spoofing approach that is optimized for the nature ofmulticast traffic in general, and more specifically, the PIM-Sparse Mode(PIM-SM) traffic forwarding model, is not currently known.

Those of skill in the art will be familiar with PIM-SM, which broadlyrefers to a version of PIM that is commonly used to establish acore-base tree to forward multicast datagrams in a network. One aspectof PIM-SM is its use to determine the core, or rendezvous point (RP)address 242, of a group of recipient network addresses, such as theirrespective class-D, or multicast, IP address corresponding to a targetcandidate RP address 242. In such an approach, the hash function ischaracterized by its ability to evenly and uniquely choose the core fora group of recipient network addresses. Furthermore, it is insensitiveto the geographic distribution of the group members and its associatedmulticast sources.

Certain embodiments of the invention may reflect an appreciation thatapproaches based upon simply disabling ingress packet filtering frommulticast traffic relies upon trusting that multicast forwarding willignore packets that fail to match the current multicast forwardingtable. Furthermore, certain embodiments of the invention may reflect anappreciation that such an approach in a router-oriented environment maybe sufficient as long as the router itself is not acting as a multicastlistener. However, in a firewall-oriented environment, where allowedtraffic is more strictly defined and logs are collected from allowed anddenied traffic, such an approach is insufficient, even if the firewall220 is not acting as a multicast listener. Likewise, certain embodimentsof the invention may reflect an appreciation that the ability to logmulticast IP packets that are actually spoofed, without false positives,would be advantageous in a firewall-oriented environment.

In certain embodiments, the automated multicast anti-spoofingconfiguration system 118 shown in FIG. 2 is implemented to automatechanges to a firewall's 220 multicast anti-spoofing configuration toimprove network security. In certain embodiments, operations forautomating the multicast anti-spoofing configuration of a firewall 220are begun by first receiving an Internet Protocol (IP) packet and thendetermining its SRC address. In turn, the SRC address is then comparedto a list of SRC addresses the external firewall 220 interface thatreceived the multicast IP packet is allowed to accept.

In certain embodiments, the particular SRC addresses the externalnetwork interfaces ‘1’ 222 through ‘n’ 224 are allowed to accept arestored in a routing information base (RIB) 230. As used herein, an RIB230 broadly refers to a database, or repository, of routing informationassociated with individual unicast IP packets. In certain embodiments,the unicast IP packets are received by the multi-access external networkinterfaces ‘1’ 222 through ‘n’ 224. In certain embodiments, themulti-access external network interfaces ‘1’ 222 through ‘n’ 224 areconfigured to receive unicast IP packets, multicast IP packets, or acombination thereof.

If it is determined that the SRC address of the IP packet received byexternal network interfaces ‘1’ 222 through ‘n’ 224 is not allowed foracceptance, information related to its receipt, examination anddiscarding are logged and the IP packet is then discarded. In certainembodiments, certain information related to the IP packet's receipt,examination and discarding may not be logged. In these embodiments, themethod of determining which information is, or is not, logged is amatter of design choice. In certain embodiments, logged informationrelated to the IP packet is stored in a repository of IP packet logentry information 236.

However, if it was determined that the SRC address of the IP packet isallowed for acceptance by the external firewall interface that receivedit, then a determination is made whether the IP packet is a multicast IPpacket. If the IP packet is not allowed for acceptance, then unicastanti-spoofing operations familiar to skilled practitioners of the artare performed. Otherwise, a determination is made whether the externalnetwork interface on the firewall 220 that received the multicast IPpacket is PIM-enabled.

In certain embodiments, individual multi-access external networkinterfaces ‘1’ 222 through ‘n’ 224 may be PIM-enabled. In certainembodiments, multicast IP packets received by the multi-access externalnetwork interfaces ‘1’ 222 through ‘n’ 224 may originate from individualPIM-enabled routers ‘A’ 204 through ‘B’ 208, ‘X’ 212 through ‘Y’ 216, ora combination thereof. In certain embodiments, the PIM-enabled routers‘A’ 204 through ‘B’ 208 and ‘X’ 212 through ‘Y’ 216 may be respectivelyassociated with external networks ‘A’ 202 through ‘B’ 206 and ‘X’ 212through ‘Y’ 214. In certain embodiments, the SRC addresses of variousmulticast IP packets may be respectively associated with a correspondingrouter, such as PIM-enabled routers ‘A’ 204 through ‘B’ 208 and ‘X’ 212through ‘Y’ 216. Likewise, individual multicast IP packets may bevariously received by an individual multi-access external networkinterface ‘1’ 222 through ‘n’ 224, or a combination thereof.

If it was determined that the multicast IP packet was not received on aenabled external network interface on the firewall 220, then routing andother information associated with the SRC address of the multicast IPpacket is compared to corresponding routing and other information storedin a multicast routing information base (MRIB) 228. As used herein, anMRIB 228 broadly refers to a collection of routing and other informationassociated with individual multicast packets. If it is determined thatthe routing and other information associated with the SRC address of themulticast IP packet matches routing and other information stored in theMRIB 228, then the multicast IP packet is considered to be not spoofed.

However, if it does not, or if it was determined the multicast IP packetwas not received by a PIM-enabled external network interface on thefirewall 220, the multicast IP packet is processed to determine thecurrent Rendezvous Point (RP) address 242 of its associated multicastgroup. As used herein, a RP broadly refers to a router in a multicastnetwork domain that acts as a shared root for a multicast shared tree.As likewise used herein, an RP address 242 broadly refers to a networkaddress associated with an RP. Skilled practitioners of the art will beaware that any number of routers can be configured to work as RPs and incertain embodiments they may be configured to cover different multicastgroup ranges.

However, if it is determined that the multicast IP packet was receivedby a PIM-enabled external network interface, the firewall's 220 settingsare then automatically configured to use the previously-determined RPaddress of the multicast IP packet in place of its SRC address toperform multicast anti-spoofing look-up operations. In certainembodiments, the automated multicast anti-spoofing configuration system118 is implemented to automatically configure the firewall's 220multicast anti-spoofing settings. In certain embodiments, the automatedmulticast anti-spoofing configuration system 118 may be implemented toprovide changes to the firewall's 220 multicast anti-spoofingconfiguration settings to the firewall configuration managementinterface 226. In these embodiments, the method by which the firewall's220 multicast anti-spoofing settings are changed is a matter of designchoice. In certain embodiments, the firewall's 220 multicastanti-spoofing settings are stored in a repository of anti-spoofingconfiguration settings 234. In these embodiments, the method by whichthe firewall's 220 multicast anti-spoofing settings are stored is amatter of design choice. Those of skill in the art will recognize thatmany such embodiments are possible. Accordingly, the foregoing is notintended to limit the spirit, scope or intent of the invention.

A determination is then made whether the RP address 242 of the multicastIP packet matches the RP address 242 of its associated active multicastjoins. As used herein, a multicast join broadly refers to one or morerecipient network addresses respectively associated with an RP address242 designated as the destination of a group of multicast IP packetsassociated with a particular multicast session. As an example, therecipient network addresses may respectively be associated with endpointdevices ‘1’ 244 through ‘n’ 246, which are in turn associated with aparticular RP address 242. In this example, the association of eachnetwork address respectively associated with endpoint devices ‘I’ 244through ‘n’ 246 with the RP address 242 results in a multicast join. Aslikewise used herein, an active multicast join broadly refers to amulticast join that is in active state, wherein a multicast source issending multicast IP packets, and one or more recipient networkaddresses are receiving them, at a particular RP address 242.

If it is determined that the RP address 242 of the multicast IP packetmatches the RP address 242 of its associated active multicast joins,then a determination is made whether logging of information related tothe multicast IP packet is required. As an example, certain governmentalregulations, or an organization's internal policies, may require loggingof information related to spoofed multicast IP packets. If it isdetermined that logging of information related to the multicast IPpacket is required, then it is logged accordingly. In certainembodiments, logged information related to the multicast IP packet isstored in a repository of IP packet log entry information 236. Incertain embodiments, the multicast IP packet is then passed to PIM forprocessing.

However, if it is determined that the RP address 242 of the multicast IPpacket does not match the RP address 242 of its associated activemulticast joins, then a determination is made whether the RP address 242of the multicast IP packet matches the RP address 242 of other activemulticast joins. If so, then a determination is then made whetherlogging of information related to the multicast IP packet is required.If it is determined that logging of information related to the multicastIP packet is required, then it is logged as described in greater detailherein.

However, if the RP address 242 of the multicast IP packet does not matchthe RP address 242 of other active joins, then it is considered to bespoofed. A determination is then made whether logging of informationrelated to the spoofed multicast IP packet is required. If not, then thespoofed multicast IP packet is discarded without logging its relatedinformation. Otherwise, information related to the multicast IP packetis logged, as described in greater detail herein, and the multicast IPpacket is discarded. In certain embodiments, the number of such logentries may be limited to a particular number. In these embodiments, thenumber of such log entries is a matter of design choice.

FIGS. 3a through 3c are a generalized flowchart of the performance ofautomated multicast anti-spoofing configuration system operationsimplemented in accordance with an embodiment of the invention. In thisembodiment, operations for automating the multicast anti-spoofingconfiguration of a firewall are begun in step 302, followed by thereceipt of an Internet Protocol (IP) packet in step 304. The source(SRC) address of the IP packet is then compared to a list of SRCaddresses the external firewall interface that received the multicast IPpacket is allowed to accept.

A determination is then made in step 308 whether the SRC address of theIP packet is allowed for acceptance by the external firewall interfacethat received it. If not, then the IP packet is discarded andinformation related to its receipt, examination and discarding areaccordingly logged, or not, in step 310. A determination is then made instep 348 whether to end operations for automating the multicastanti-spoofing configuration of a firewall. If so, then operations forautomating the multicast anti-spoofing configuration of a firewall areended in step 350. Otherwise, the process is continued, proceeding withstep 304.

However, if it was determined in step 308 that the SRC address of the IPpacket was allowed for acceptance by the external firewall interfacethat received it, then a determination is made in step 312 whether theIP packet received in step 304 is a multicast IP packet. If not, thenunicast anti-spoofing operations familiar to skilled practitioners ofthe art are performed in step 314 and the process is continued,proceeding with step 348. Otherwise, a determination is made in step 316whether the external network interface on the firewall that received themulticast IP packet is Protocol-Independent Multicast (PIM) enabled. Ifnot, then the routing of the SRC address of the multicast IP packet iscompared to routing and other information stored in a multicast routinginformation base (MRIB) in step 318.

A determination is then made in step 320 whether the routing of the SRCaddress and other information related to the multicast IP packet matchesrouting and other information stored in the MRIB for the externalinterface on the firewall that received it. If so, the process iscontinued, proceeding with step 348. Otherwise, or if it was determinedin step 316 that the multicast IP packet was received by a PIM-enabledexternal interface on the firewall, then the multicast IP packet isprocessed in step 322 to determine the current Rendezvous Point (RP)address of its associated multicast group. The firewall is thenautomatically configured in step 324, as described in greater detailherein, to use the RP address determined in step 322 in place of the SRCaddress of the multicast IP packet to perform multicast anti-spoofinglook-up operations. A determination is then made in step 326 whether theRP address of the multicast IP packet matches the RP address of itsassociated active joins, as described in greater detail herein.

If so, then a determination is made in step 328 whether logging ofinformation related to the multicast IP packet is required, as likewisedescribed in greater detail herein. If so, then information related tothe spoofed multicast IP packet is logged in step 330. Once theinformation related to the multicast IP packet has been logged in step330 as being spoofed, or if it was determined in step 328 to not loginformation related to the multicast IP packet, the multicast IP packetis passed to PIM for processing. The process is then continued,proceeding with step 348.

However, if it was determined in step 326 that the RP address of themulticast IP packet does not match its associated active joins, then adetermination is made in step 334 whether the RP address of the spoofedmulticast IP packet matches the RP address of other active joins. If so,then a determination is made in step 336 whether logging of informationrelated to the multicast IP packet is required. If so, then informationrelated to the multicast IP packet is logged in step 338. Otherwise, orif it was determined in step 336 that logging of information related tothe multicast IP packet is not required, then the process is continued,proceeding with step 348.

Once the spoofed multicast IP packet has been discarded in either step336 or step 338, the process is continued, proceeding with step 340.However, if it was determined in step 334 that the RP address of thespoofed multicast IP packet does not match the RP address of otheractive joins, then it is considered to be spoofed. Accordingly, adetermination is made in step 340 whether information related to thespoofed multicast IP packet is required. If not, the multicast IP packetis discarded without logging its related information and the process iscontinued, proceeding with step 348.

Otherwise, information related to the spoofed multicast IP packet islogged in step 344. In certain embodiments, the number of such logentries may be limited to a particular number within a certain period oftime (e.g., five log entries per minute). In these embodiments, thenumber of such log entries within a particular interval of time is amatter of design choice. The spoofed multicast IP packet is thendiscarded in step 346 and the process is continued, proceeding with step348.

As will be appreciated by one skilled in the art, the present inventionmay be embodied as a method, system, or computer program product.Accordingly, embodiments of the invention may be implemented entirely inhardware, entirely in software (including firmware, resident software,micro-code, etc.) or in an embodiment combining software and hardware.These various embodiments may all generally be referred to herein as a“circuit,” “module,” or “system.” Furthermore, the present invention maytake the form of a computer program product on a computer-usable storagemedium having computer-usable program code embodied in the medium.

Any suitable computer usable or computer readable medium may beutilized. The computer-usable or computer-readable medium may be, forexample, but not limited to, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, ordevice. More specific examples (a non-exhaustive list) of thecomputer-readable medium would include the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a portable compact disc read-only memory (CD-ROM), anoptical storage device, or a magnetic storage device. In the context ofthis document, a computer-usable or computer-readable medium may be anymedium that can contain, store, communicate, or transport the programfor use by or in connection with the instruction execution system,apparatus, or device.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language suchas Java, Smalltalk, C++ or the like. However, the computer program codefor carrying out operations of the present invention may also be writtenin conventional procedural programming languages, such as the “C”programming language or similar programming languages. The program codemay execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Embodiments of the invention are described with reference to flowchartillustrations and/or block diagrams of methods, apparatus (systems) andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

The present invention is well adapted to attain the advantages mentionedas well as others inherent therein. While the present invention has beendepicted, described, and is defined by reference to particularembodiments of the invention, such references do not imply a limitationon the invention, and no such limitation is to be inferred. Theinvention is capable of considerable modification, alteration, andequivalents in form and function, as will occur to those ordinarilyskilled in the pertinent arts. The depicted and described embodimentsare examples only, and are not exhaustive of the scope of the invention.

Consequently, the invention is intended to be limited only by the spiritand scope of the appended claims, giving full cognizance to equivalentsin all respects.

What is claimed is:
 1. A computer-implementable method for performing anautomated anti-spoofing configuration operation, comprising: determiningwhether a source address of an internet protocol (IP) packet is allowedby a receiving interface of a firewall; determining whether the IPpacket comprises a multicast packet when the IP packet is allowed by thereceiving interface of the firewall; replacing the source address with arendezvous point address; using the rendezvous point address todetermine whether routing path information associated with the multicastpacket matches information stored within a multicast routing informationbase for the receiving interface of the firewall; and, identifying themulticast packet as spoofed when the routing path information associatedwith the multicast packet does not have corresponding information storedwithin the multicast routing information base; comparing the rendezvouspoint address of the multicast packet with a rendezvous point addressfor any active multicast joins to determine whether the rendezvous pointaddress of the multicast packet has an associated active multi castjoin; and, identifying the multicast packet as spoofed when therendezvous point address does not have an associated active multicastjoin.
 2. The method of claim 1, wherein: the receiving interface of thefirewall comprises a network interface.
 3. The method of claim 1,wherein: the active multicast join comprises a recipient network addressassociated with a rendezvous address designated as a destination of agroup of multicast packets associated with a particular multicastsession.
 4. The method of claim 1, further comprising: determiningwhether logging of the multicast packet is required; and, logginginformation relating to the multicast packet when logging of themulticast packet is required.
 5. The method of claim 1, furthercomprising: determining whether the multicast packet is received by aProtocol independent Multicast (PIM) enabled interface of a firewallwhen the IP packet comprises the multicast packet.
 6. A systemcomprising: a processor; a data bus coupled to the processor; and anon-transitory, computer-readable storage medium embodying computerprogram code, the non-transitory, computer-readable storage medium beingcoupled to the data bus, the computer program code interacting with aplurality of computer operations and comprising instructions executableby the processor and configured for: determining whether a sourceaddress of an internet protocol (IP) packet is allowed by a receivinginterface of a firewall; determining whether the IP packet comprises amulticast packet when the IP packet is allowed by the receivinginterface of the firewall; replacing the source address with arendezvous point address; using the rendezvous point address todetermine whether routing path information associated with the multicastpacket matches information stored within a multicast routing informationbase for the receiving interface of the firewall; and, identifying themulticast packet as spoofed when the routing path information associatedwith the multicast packet does not have corresponding information storedwithin the multicast routing information base; comparing the rendezvouspoint address of the multicast packet with a rendezvous point addressfor any active multicast joins to determine whether the rendezvous pointaddress of the multicast packet has an associated active multicast join;and, identifying the multicast packet as spoofed when the rendezvouspoint address does not have an associated active multicast join.
 7. Thesystem of claim 6, wherein: the receiving interface of the firewallcomprises a network interface.
 8. The system of claim 6, wherein: theactive multicast join comprises a recipient network address associatedwith a rendezvous address designated as a destination of a group ofmulticast packets associated with a particular multicast session.
 9. Thesystem of claim 6, wherein the instructions executable by the processorare further configured for: determining whether logging of the multicastpacket is required; and, logging information relating to the multicastpacket when logging of the multicast packet is required.
 10. The systemof claim 6, wherein the instructions executable by the processor arefurther configured for: determining whether the multicast packet isreceived by a Protocol independent Multicast (PIM) enabled interface ofa firewall when the IP packet comprises the multicast packet.
 11. Anon-transitory, computer-readable storage medium embodying computerprogram code, the computer program code comprising computer executableinstructions configured for: determining whether a source address of aninternet protocol (IP) packet is allowed by a receiving interface of afirewall; determining whether the IP packet comprises a multicast packetwhen the IP packet is allowed by the receiving interface of thefirewall; replacing the source address with a rendezvous point address;using the rendezvous point address to determine whether routing pathinformation associated with the multicast packet matches informationstored within a multicast routing information base for the receivinginterface of the firewall; and, identifying the multicast packet asspoofed when the routing path information associated with the multicastpacket does not have corresponding information stored within themulticast routing information base; comparing the rendezvous pointaddress of the multicast packet with a rendezvous point address for anyactive multicast joins to determine whether the rendezvous point addressof the multicast packet has an associated active multicast join; and,identifying the multicast packet as spoofed when the rendezvous pointaddress does not have an associated active multicast join.
 12. Thenon-transitory, computer-readable storage medium of claim 11, wherein:the receiving interface of the firewall comprises a network interface.13. The non-transitory, computer-readable storage medium of claim 11,wherein: the active multicast join comprises a recipient network addressassociated with a rendezvous address designated as a destination of agroup of multicast packets associated with a particular multicastsession.
 14. The non-transitory, computer-readable storage medium ofclaim 11, wherein the computer executable instructions are furtherconfigured for: determining whether logging of the multicast packet isrequired; and, logging information relating to the multicast packet whenlogging of the multicast packet is required.
 15. The non-transitory,computer-readable storage medium of claim 11, wherein the computerexecutable instructions are further configured for: determining whetherthe multicast packet is received by a Protocol Independent Multicast(PIM) enabled interface of a firewall when the IP packet comprises themulticast packet.
 16. The non-transitory, computer-readable storagemedium of claim 11, wherein: the computer executable instructions aredeployable to a client system from a server system at a remote location.17. The non-transitory, computer-readable storage medium of claim 11,wherein: the computer executable instructions are provided by a serviceprovider to a user on an on-demand basis.